Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9607/000004_owner-urn-ietf _Mon Jul 8 14:36:17 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03530 for urn-ietf-out; Mon, 8 Jul 1996 14:36:17 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03525 for <[e-mail]>; Mon, 8 Jul 1996 14:36:15 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA14788  (mail destined for [e-mail]); Mon, 8 Jul 96 14:36:13 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA04275 for <[e-mail]>; Mon, 8 Jul 1996 12:36:12 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 08 Jul 1996 12:40:16 -0600
To: [e-mail]
From: Ron Daniel <[e-mail]>
Subject: [URN] nasty rewriting rules
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Hi gang,

At the URN BOF in Montreal, a fair amount of concern was expressed about
how complex systems of rewrite rules can become. One of the first things
we need to talk about on this list is the rewrite rule feature of the
NAPTR draft, what led us to rewrite rules, and whether we want to try
again for a solution without them. The point of this message is to start
a thread on the subject of the NAPTR rewrite rules to find out if the
rough concensus of the group is to keep them, scrap them, or if there is
no real concensus on them.

For background, the current version of the NAPTR draft can be snarfed
from  http://www.acl.lanl.gov/URN/naptr.txt
The original version is available from
http://www.acl.lanl.gov/URI/naptr-00.txt
in case you want to fetch it.


First, what do we mean by a "rewrite rule"? This is a rule we apply to the
URN to obtain a domain name to query. Note that rewrite rules in the NAPTR
proposal are always applied to the original URN, never to the result of a
previous rewrite rule. The rules take two major forms. One is simply
providing the domain name that is sought. The second is to use a regular
expression substitution to extract part of the URN, mung it around, and
produce the domain name. The newest version of the NAPTR proposal has split
the original "pattern" field into seperate "replacement" and "regexp" fields
that correspond to these types of rewrite rules. (This was so that the
replacement names could be compressed in the standard DNS fashion).

Second, who has to know about rewrite rules? Not end-users. Their
client software (perhaps with the aid of a proxy) will do the rewriting
for them. The domain administrators at every site that wants to provide
resources by means of a URN scheme will need to know about them. For most
sites we anticipate that the rewrite rule will be a replacement domain
name. The difficulty of getting this correct is somewhat greater than
getting a CNAME record correct, but the records are analogous. Sites
with sophisticated delegation needs will need a more complex system of
NAPTRs, with a corresponding increase in the difficulty of correct
configuration.

The main thing that led us to rewrite rules was was the grandfathering
requirement in the URN requirements RFC. Most
candidate naming systems will have some hierarchical naming authority and
a string assigned by that authority. The order and position of the
hierarchy, as well as delimiter characters, will vary. If we are to
accomodate other naming systems, we needed a mechanisim that could cope
with such variability. The regexp-based rewrite rules are what we came
up with.

One of the pleasant side effects of the grandfathering requirment was that
in meeting it, we also came up with something that met the main principle
in the Knoxville work - that name assignment should be decoupled from
name resolution. The rewrite rules give us a means of associating new
information with components of names, in a manner that is invisible to
the end-user.

At the BOF it was mentioned that the grandfathering requirement
was worded such that it had low priority, and that having seen what the
requirement led to (rewrite rules) we might want to eliminate that
requirement. My personal opinion is that we should keep the requirement,
and the rewrite rule portion of the NAPTR proposal. What say you?

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"